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^ ■ Abstract 

a, 

We present the design of the simulation package Pluto, aimed at the study of hadronic 
interactions at SIS and FAIR energies. Its main mission is to offer a modular framework 
I with an object-oriented structure, thereby making additions such as new particles, decays 

^ ' of resonances, new models up to modules for entire changes easily applicable. Overall 

lO ■ consistency is ensured by a plugin- and distribution manager. Particular features are the 

^ i support of a modular structure for physics process descriptions, and the possibility to access 

I the particle stream for on-hne modifications. Additional configuration and self-made classes 

^ ■ can be attached by the user without re-compiling the package, which makes Pluto extremely 

O . configurable. 

> 

H : 1 Introduction 

Due to the fact, that experimental setups are usually not suited to cover the complete complete 
phase space, event generators are very important tools for experiments. Practically, the experi- 
mental physicist needs a tool in hand which allows to control almost all kinematic variables with 
a manageable user interface and to exchange the physics models which have to be compared to 
measured data. 

In our contribution, we present the software structure of the Pluto event generator [1] originally 
developed for the HADES experiment [|2l but successfully used by other collaborations in the 
hadronic physics field as well. Its recent redesign partly discussed in this contribution enhanced 
its flexibility and provide new features which allow to meet new challenges coming with the 
detector studies for the new FAIR experiments PANDA [iSJ and CBM [|41. 
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Pluto is a collection of C++ classes, adding up to the framework of a simulation package for 
hadronic physics interactions in the energy regime up to a few GeV. It is launched interactively 
within the ROOT [5] environment, and makes use of ROOT only, without requiring additional 
packages. The focus is on streamlining particle generators by providing the tools to set up and 
manipulate particles, reaction channels, and complex reactions, as well as applying experimen- 
tal filters on the reaction products, such as geometrical acceptance and kinematical conditions. 
Typical simulations may be executed with a few lines of input, with no expertise required on the 
part of the user. It standardizes simulations by providing a common platform that is accessible 
via the analysis environment (ROOT), with a straightforward user interface that does not inhibit 
non-experts in simulations. 

The output may be analyzed on line, or further forwarded to a digitization package. The Pluto 
framework includes models for hadronic and electromagnetic decays, resonance spectral func- 
tions with mass -dependent widths, and anisotropic angular distributions for selected channels. A 
decay-manager interface enables "cocktail" calculations. An extensive particle data base is avail- 
able, with capabilities to support user-defined ones. Various particle properties and decay modes 
are included in the data base. Thermal distributions are implemented, enabling multi-hadron 
decays of hot fireballs. 

The general philosophy of Pluto is that on one hand the users should be able to drive the package 
in a very easy way, but on the other hand are allowed to customize it without much restrictions. 
This means that the steering application has the opportunity to add new decays/particles among 
with new models up to the incorporation of plugin^. 

The structure and design of Pluto are sketched in Fig. [TJ The framework can be roughly divided 
into 3 parts: a user interface for event production, a physics package, and an event loop interface. 
In this report we would like to concentrate on the latter two issues: the first one allows to add 
and/or select physics cases, where models can be either build-in models or runtime replacements, 
which will be discussed in Sec. [2l This area of Pluto works even outside the event loop for 
the calculation of parameters (mass distributions, decay widths,...). The other block allows for 
external particle decay and acceptance filter classes (see Sec. [3]) and filling of on-line histograms 
(see Sec.g]). 

As the interface for event production is described in detail elsewhere fP| in this context we will 
give only a short example. After all models have been configured accordingly, an elementary 
reaction chain is defined with a character string containing the reaction products. To perform, 
e.g., the production in the pp reaction with a consecutive Dalitz decay as discussed in the 
following sections, the commands as defined below are sufficient: 

PReaction *r = new PReact ion ( " 1 . 2 5 " , "p" , "p" , 

"p D+ [p dilepton [e+ e-] ]"); 

r->Print ( ) ; 
r->Loop (10000) ; 

'The PC gaming industry, making benefit from charge-free down-loadable packages, calls such extension fea- 
tures also "mod". 
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Figure 1 : Structure and design of Pluto: the (orange) boxes in the upper left show the user classes 
to set up and handle reactions (and decay channels). The (yellow) box on the left is the interface 
for accessing the particle stream while the event loop is running. The (blue shaded) boxes in the 
lower right comer represent the data base for the particles and decays among with a user interface 
for customization. The (light blue) boxes above are the distribution interface and the included 
physics models (color online). 



with the number 1.25 as the kinetic beam energy in GeV, the beam and target particle indicated 
by following two options and finally a string describing the decay. Particles are defined via their 
data base name (as "p" for a proton or "D + " for a A+). The setup of the reaction channels 
and the attachment of all selected distributions and models is done by the framework, with the 
possibility to dump the complete chain and its models via the Print () method. Finally, the 
command Loop (n) produces n events. 

Then, event-event-by-event, the individual steps in each reaction are executed via a common 
interface of all classes making distributions (see [IJ for details) which do the calculation of final 
particle tracks (also the unstable ones) which are stored in an array. 



2 The models 

2.1 Architecture 

In the Pluto framework, each physics process is described by a number of objects, instantiated 
from dedicated classes. Beside the objects which communicate with the event loop and set the 
4-momenta of the resulting particle tracks (to form the above-mentioned "distributions"), Pluto 
offers methods to make calculations including various channels and their accompanied functions 
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in advance to (or event without) the event-loop. For this purpose, a relative data base has been 
included, which connects particles and decays to "models". At least one (so-called ''primary") 
model is needed per decay in order to describe the respective mass shape (usually calculated 
by a mass-dependent Breit-Wigner in a recursive way) and the partial/total decay width. Each 
selected model can be accessed from all locations of the software package as well as by the user. 

The choice which of the allover offered physics models are linked to the data base can be done 
inside the production ROOT-macro by calling a distribution manager (for details about the han- 
dling see [1]), which itself takes care that only one primary model per decay and particle is 
selected, respectively. Moreover, Pluto offers the user the freedom to attach user-defined mod- 
els based on its own sources or even new classes (written in C-i-i-) at runtime, thereby replacing 
built-in models. These features make Pluto an extremely versatile and highly configurable tool 
for simulations, while guaranteeing overall consistency at all times. 

One specific feature of Pluto is that we do not use monolithic decay models only but allow for 
the splitting of the underlying physics process into different models in a very granular way (e.g., 
to exchange form factors or total cross sections). This turned out to be a very important tool 
in order to check various scenarios along with measured data. Therefore Pluto allows for the 
attachment of secondary models for all kinds of purposes. Here, a secondary model is an object 
for a particle/decay returning a (complex) number as a function of a defined number of values. 
We do not attempt to have a base class for each kind of function and model (e.g., a total cross 
section base class, a base class for dV/dm, etc.) because this makes further extensions difficult. 
Our approach is as follows: for each class of secondary models a new entry (defined by a unique 
name) is added dynamically to the data base. Consequently, each model is bound to two data 
base keys: one to link it to a decay (or particle) and one more for the type of secondary model. 

Anyhow, there the user does not need to take care about these issues, as the following template 
example shows. 

2.2 Template example 

In Pluto, each model is inherited from the base class PChannelModel with a lot of useful 
features. In order to offer the result of the calculation the GetWeight ( ) method has to im- 
plemented. Let us create such an example class as a template for the following discussion and 
future developments: 

class PHelperFunct ionTest : public PChannelModel { 
public : 

PHelperFunct ionTest (const Char_t *id, const Char_t *de. 



Int_t 

Double_t GetWeight (Double. 



key) ; 

t *x, Int_t *opt=NULL) ; 



} 



with an realization of the (in this case 1 -dimensional) function: 
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Double_t PHelperFunct ionTest : : GetWeight (Double_t *x, 

Int_t *opt) { 

Double_t XX = x[0]; 
val = ... 

return val; 

}; 

Objects can be instantiated to work as a model for specific physics processes by the usage of a 
parser residing inside the constructor of the base class: 

PHelperFunct ionTest *obj = new 

PHelperFunct ionTest ( "unique_name@D+_to_p_dilepton/helper " , 

"Test", -1) ; 

Here, the unique_name is used to identify the object inside the distribution manager. The 
string hereafter binds the new object to a decay which is in this case A+ p'j*. The optional 
appendix /helper enables the new object to be a secondary model of this type. 

Let us now assume, the primary model has to access its helper function. In this case it is sufficient 
to execute the following command at a single place (an I nit ( ) function is available for that): 

PChannelModel *sec_model=GetSecondaryModel ( "helper" ) ; 

and execute the daughter method sec_model->GetWeight (value) whenever required. 
The access to alien secondary models is possible as well but a further discussion on this topic 
would exceed the scope of this report. 

2.3 Example: form factors 

The power of such a splitting can be demonstrated best with an real example. For this purpose let 
us use the study of the electromagnetic A Dalitz decay A NY Ne'^e^. As explained in 
the introduction Pluto reads this as a multi-step process: in the first step, the A mass is sampled 
using a mass-dependent width. In the second step, the already sampled A mass rriA is used by 
the following Dalitz decay model to sample the di-electron (=virtual photon) mass m^e- 

By using a dedicated plugin: 

makeDistribut ionManager () ->Exec ( "dalitz_mod: krivoruchenko" ) ; 

the following model for the di-electron mass spectrum is enabled, using the prescription of 
Ref. [i6J with: 
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and the decay rate given by Krivoruchenko etalffl: 



V, 




a (mA + 



y+y'-, 



y± 



16 m^mj^ ^ 



ee 



(2) 



where the index refers to the produced nucleon, e is the electron charge, and G^^'^* (m^. ) 
represents the electromagnetic transition amplitudes. Here, from the software point of view, it 
is important to know that this factor is a separated object in Pluto making the addition of new 
complementary descriptions very easy. This avoids the usage of nasty flags which is error-prone. 
E.g., following the QED approach (assuming that no hadronic transition form factor is involved) 
from Ref.[.7J gives: 



with Gm, Ge, and Gc as the magnetic, electric and Coulomb transition form factors. 

Alternatively, one can switch to the VMD-like form factor of lachello and Wan (HI which is 
already implemented and will be discussed in detail in a further, separate publication. 

After activating this plugin, both above-mentioned versions (VMD and QED) are offered, ap- 
pearing as objects with their unique names in the directory-like distribution manager structure. 

makeDistribut ionManager () ->Print ("vmd") ; 



PDistribut ionManager 



root Root group: 494 objects (of 504), 

subgroups : 9 

part icle_models Mass sampling of particles : 27 objects 

(of 29) 

decay_models Phase space mass sampling & decay partial 




(3) 



polar_angles 



genbod_models 



widths: 219 objects (of 225) 
Polar angles in elementary particle 

production: 10 objects (of 10) 
Momentum sampling: 220 objects (of 220) 



vmd 
) D+_vmd_ff 
(X) D+_qed_ff 



VMD form factors: objects (of 2) 
VMD ff for D+ -> p e+e- 
QED ff for D+ -> p e+e- 



qed 



QED form factors: 2 objects (of 2) 
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Figure 2: The bulk interface. 



Possible conflicts between the QED and VMD models are indicated. The user can now activate 
all models inside the directory via: 

makeDistribut ionManager () ->Enable ("vmd") ; 



3 The event loop interface 

The aim of the event loop interface is to allow access to the particle bulk before it is writ- 
ten to disk by providing an interface for bulk decays (also using 3'''^ party event generators 
such as Pythia [|9||), file access, implantation of embedded particles for detector studies, and 
filter classes. It works - like indicated in Fig. [21 - by stacking individual bulk classes (by 
PReaction : : AddBulk (PBulklnterf ace * ob j ) ) and making use of the base-class 
Modify method which handles the embedding and removing of particles or mark them as 
decayed/invalid. 

Like in the previous section, user classes can be compiled - if needed - and added on-the-fly, 
which could be very helpful in the context of FAIR experiments studies, as the following appli- 
cations show: 



3.1 File access: 

Particle tracks might be added from (or written to) user files in any self-defined format. This 
feature makes Pluto open for other collaborations and enables it to be used as an "afterburner" 
for externally created simulation data or output of transport models. 



3.2 Embedded particles: 



Test particles can be embedded into a background reaction which is an important tool for detec- 
tors studies, e.g. to test tracking in a high multiplicity environment. Moreover, among with the 
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previous feature the mixing of embedded particles with either real events or S^'' party simulation 
is one of the applications. In the first case, the reconstructed vertex of the analyzed experimental 
data is used to simulate rare probes (as the di-electrons) at exactly the same vertex. In this way 
the efficiency of these probes can be calculated with the best background one can have, namely 
measured data. 



3.3 Bulk decay: 

In addition to a well defined reaction chain, Pluto offers free "bulk" decays, i.e. the decay of 
(embedded) particles following the calculated mass-dependent branching ratios. At this stage it 
is possible as well to employ 3'"'^ party event generators. Only to give an example: Pluto can 
generate embedded particles like resonances with a selected distribution and the Pythia package 
(or Pluto itself) can be used for their realistic free decay. 

3.4 Detector acceptance class: 

The particles created in the previous steps can be pre-filtered using a "detector acceptance" user 
class following a class definition as outlined below: 

class PMyDetector : public PBulklnterf ace { 
private : 

Double_t *acc; 
public : 

Bool_t Modify (PParticle ** stack, int *decay_done, int * num, 
int stacksize) ; 

}; 

PMyDetector :: PMyDetector ( ) { 

acc = makeStaticData ( ) ->GetBatchValue ( "acc_value" ) ; 

}; 

with acc_value as a booked batch value (see below for more information) and, e.g.: 

Bool_t PMyDetector : iModify (PParticle stack, ... ) { 
*acc=l . ; 

for (int 1=0; i< *num; i++) { 
PParticle * cur = stack [i]; 
if ("check for cur") *acc=0 . ; 
} 

} 
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Figure 3: Overview of the PProjector design. 



4 Projecting events 
4.1 General idea 

The usual way to analyze generated events (beside a full Monte-Carlo production including dig- 
itization) is to open the simulation file with an appropriate analysis macro, loop over the num- 
ber of events, read the particle objects and do the required operations inside the loop. E.g., 
in hadronic physics, in particular for exclusive studies, usually missing and invariant masses 
are reconstructed, and possibly after boost operations angular correlations are investigated. In 
addition, signal selection has to be done not only on a single track level but using particle corre- 
lations (such as a invariant/missing mass selection). This prevents to use the features provided 
by TTree : : Draw ( ) only, as these are fixed to single track properties. 

The main aim of the "PProjector" (see Fig. [3]) is to offer a simplified analysis method fol- 
lowing a similar idea as TTree : : Draw ( ) in order to project particles (and their correlations) 
onto on-line histograms and/or TNtuples by making use of the bulk interface described in the 
previous section. This means, no analysis macro is needed for a large number of typical observ- 
ables. 

There are two ways to include the projector into the event loop. Either one or more of its in- 
stances are added to the bulk interface (for an alternating mixing with other classes), or, which is 
sufficient for the most cases, the short version PReact ion :: Do (char * command) canbe 
used, where command follows a C-i-i-like (but more simple) syntax. Each of these commands - 
just forming steps in a batch - is executed inside the event loop. 



4.2 Histograms 



To fill histograms one can use the extended method PReaction: :Do (THx * histo, 
char * command) where histo points to a 1/2/3-dimensional histogram. 
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In this case the command has to define the key variables _x, _y and _x as the respective 
axis value, depending on the chosen dimension of his to. The Pluto particle array objects 
can be accessed via its Pluto particle name inside brackets as [name, num] with the optional 
num as the consecutive number of equal particles inside each event. All objects can be com- 
bined with a number of build-in methods, moreover all browsable methods of the ROOT-class 
TLorentz Vector can be employed, as the following example indicates: 

r->Do (histol, "_x = [D+]->M()"); 

which fills the 1-dimensional histol with the A+ mass. Invariant masses (composite particles) 
can be formed by adding the objects: 

"_x = ( [e+] + [e-] ) ->M2 " 

and stored for a consequent use in semi-colon separated sub-commands without requiring a 
"new" operator: 

"dilepton = ( [e+] + [e-] ) ; _x = dilepton->M2 ( ) " 

Let us now come to a more complex example, which is the calculation of the polar emission 
angle of one of the outgoing protons in a p + p reaction (N.B. Pluto treats the cm. system as a 
particle named p + p): 

"pi = [p,l]; pl->Boost ( [p + p] ) ; _x = cos (pl->Theta ( ) ) " 

In this example, in the first sub-command the first appearing proton is copied to the object pi 
which is furthermore boosted into the cm. energy frame and in the last step the cosine of its 
polar angle is written as a value to the x-axis. 

4.3 TNtuple in- and output 

The projection to TNtuples turned out to be very useful as it allows to make additional se- 
lections (and definition of the histogram axis) afterwards which is a very simple task using the 
PProjector following the syntax as described above. Let us now assume, the momenta of 
simulated ?7's should be stored. Then the first step would be to define the TNtuple with branch 
names: 

TNtuple *ntuple = 

new TNtuple ( "ntuple" "eta_px : eta_py : eta_pz " ) ; 

Hereafter, the Do () -method has to be called like in the above-indicated example but with a 
pointer to a TNtuple-object instead of a histogram and the variable names of the ntuple instead 
of the axis names: 
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"eta_px = [eta]->Px(); eta_py = [eta]->Py(); 
eta_pz = [eta]->Pz()" 

The filling of the ntuple is done by Pluto, only (but on purpose) the opening and closing of the 
root-file has to be called externally. 

In addition to the writing of TNtuples it is also possible to read (back) any ntuple, modify its 
values and write it back or make histograms. Let us use the ntuple of the previous example which 
uses the ntuple (usually from a file) and defines an empty reaction, but attaches the ntuple as a 
3rd party input: 

PReaction my_reaction; 
my_reaction . Input (ntuple) ; 

The next step is to use the branches of the ntuple in the batch command line to, e.g., reconstruct 
the 4-momentum: 

"myeta = P3M (eta_px, eta_py, eta_pz, . 54745) " 

with P3M as the short syntax for a vector constructor with 3 momenta and the particle mass as 
parameters. At this point any kind of mathematical operation available via TFormula can be 
applied as well. Finally using Loop ( ) without a number reads all events from the ntuple. 

4.4 Filter commands 

The employment of batch commands allows to define on-line filters on single particle properties 
as well as kinematic variables which are accessible as indicated above. These filters can be 
used to select events for single histograms only or forwarded to the event loop to apply physical 
constraints, before a full event is written to disk, hence reducing the event file. Variables prepared 
in a detector class as outlined in Sec. l3.4l can be integrated very easily. 

This is realized by using the if -command, followed by the variable or a combined condition 
based on particle observables. The remaining batch sub-commands are executed only under a 
positively evaluated condition. It goes without saying that the condition statement can combine 
all methods among with the established TFormula syntax: 

"if(obj->P() > 0.3 && obj->P() < 0.6); dowhatever . . . " 

In this case, histograms and ntuples in the Do ( ) method are only filled under the defined condi- 
tion, or, "dowhatever" can be used to re-define variables. 

In this context, it should be noted, that variables, starting with "#" are interpreted by the Pluto 
event loop as a condition for the final event file. In our next case, an event is accepted if both the 
electron and the positron are produced with polar angles in the range of 18 to 85 degrees: 
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"theta_ep = ( [e+] ->Theta ( ) * 1 8 . ) /TMath : : Pi ( ) " 
"theta_em = ( [e-] ->Theta ( ) * 1 8 . ) /TMath : : Pi ( ) " 
"#filter = 1; if (theta_ep<l 8 || theta_ep>85 || theta_em<18 

theta_em>85) ; #filter = 0" 

by this means it is only a single step to activate the detector class MyDetect or from Sec. I3.4[ 

"#acc_filter = acc_value" 

and optionally combine the prepared acceptance flag with our kinematical conditions. 

5 Summary 

In summary, we presented new developments for the Pluto event generator which moves this 
package from being a pure event generator to a comprehensive framework. The particular fea- 
tures are the bookkeeping of various models and the user interface for their simple selection. The 
new event loop interface allows to mix several sources, to define and enable online selections, 
project to histograms and to make a lot of operations. Detector acceptance and resolution can 
be included without much overhead, which is of particular importance for detector studies in the 
context of the FAIR project. 

In the near future, we will implement general purpose resolution scenarios using a common data 
format and file readers to transport models (like UrQMD [,101 and HSD [11]). This will allow to 
test very rapidly the performance of different detector configuration options. 
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